Various mechanisms for indicating the occurrence and/or extent of telephone calls or other voice/multimedia signals over a switched network are well known. Channel Associated Signaling (CAS), for example, remains widely used in voice media gateways (MGs) of many developing countries in conjunction with R2 signaling protocols for detecting pulse train type metering signals used in billing telephone calls. Such mechanisms typically provide a digital signal processor (DSP) within an MG that receives predetermined signal detection constraints from an MG controller or by user via configuration interface. For simplicity we are considering only the first case in this document. The DSP uses the constraints to identify received pulse train pulses for determining a pulse count or train frequency, and transmits a resultant value back to the MG controller (MGC). However, conventional signal handling may well fail to meet sometimes competing operational characteristics, such as scalability, accurate signal detection, efficient and complete signal reporting, and count or statistical information preservation.
Representative conventional R2 variants include predetermined signal processing constraints: minimum recognition time (MinMake), maximum recognition time (MaxMake), minimum break time (MinBreak), maximum break time (MaxBreak), current receive pattern (CurrRx), previous Rx Pattern (PreRx) and current transmit pattern (CurrTx).MG receives from the MGC the following: a pulse-reporting variant, a pulse count reporting variant and a frequency change reporting variant.
Pulse-reporting R2 variants provide for detecting and reporting to an external application (executed on a different processor) each pulse occurring in conjunction with each telephone call handled by the MG. The external application counts the number of pulses received during a succession of fixed time durations to detect pulse train frequency changes, and informs the media gateway controller (MGC) of the changes. Unfortunately, fixed period frequency detection with ongoing pulse reporting is incapable of assuring accurate pulse detection or efficient reporting (e.g., see FIGS. 1A and 1B). It also lacks scalability for handling high call rates. For example, based on an origination and destination of a call, as many as three metering pulses per second could be received during a call. In high-density gateways such as a 48E1-compatible gateway (having 1536 ports) the number of pulses that the application processor receives from DSP may therefore be on the order of 4608 pulses per second—well above this variant's ability to conduct pulse tracking and reporting.
In current pulse count reporting, the DSP counts the number of pulses that are received by the MG on a particular channel and the external application polls the DSP for a pulses count at various times. The application then attempts to use the received pulse count to derive the frequency of the incoming pulse train. Unfortunately, high call volumes may nevertheless result in low system performance; conversely, too low of a call volume may produce a delay in reporting pulse train metering and result in erroneous call charge reporting. Worse yet, a DSP/system malfunction (e.g., DSP crash or system reset) may well result in a standby system having an incorrect number of pulses as having been detected by a previously active DSP. Thus, while a newly active card (NAC) may attempt to derive a number of pulses received by a previously active card (PAC), a frequency change just before an application polls the DSP would result in incorrect information being conveyed to the MGC.
In basic frequency change reporting mechanisms, DSP counts the number of pulse train pulses received in successive predetermined, fixed time durations (e.g., indicated as fixed durations 102 and 112 of FIGS. 1A and 1B respectively) and calculates a pulse frequency corresponding to each detected fixed-duration number of pulses. Unfortunately, such a mechanism may result in an excessive number of frequency-change-notifications (FCN) to the application—even where the pulse train frequency is static. (e.g., see pulse train 110 of FIG. 2). While hysteresis-correcting algorithms might be used, reporting of even a slight valid change may be delayed, resulting in errors in applications such as call charge metering.
The above R2 variants also share certain common problems. For example, the predetermined and fixed manner in which the DSP operates may not be desirable in conjunction with a particular application. The predetermined and fixed pulse tracking that is reported, polled or used to calculate a then reported frequency is also, in each case, subject to producing erroneous results, among other problems.
Accordingly, there is a need for a mechanism that avoids the problems encountered with conventional CAS implementations.